1. Field of the Invention
The present invention relates to software development and, more particularly, to software development tools.
2. Description of the Related Art
Modern software is complex in nature and typically is formed of a collection of many different files. Because the size and complexity of the files themselves can be significant, it is common practice to assign responsibility for developing and maintaining each file to a team of developers. When two developers make changes to a same file in parallel, however, it becomes necessary to combine the contributions of each individual and/or team into a single file that is to be incorporated into a software build.
Software development tools such as configuration management systems or source code control systems are used to track and manage the different file versions created for a given software build. Such systems are capable of combining, or merging, the contributions of different individuals or teams into a resulting file called a merge file. Generally, the source code control system automatically compares two or more different versions of a file, whether source code files, modeling language files, or other electronic documents. Any differences between the compared files are identified by the tool and a merge operation is performed.
Merging unstructured text files is a relatively simple operation since text files have no relationship from one line to the next. In contrast, merging source code files can be much more difficult since line to line changes may affect the integrity of structured units within the file such as methods and the like. The more structured the content of the file versions to be merged, the more difficult the merge operation becomes due to complex internal multi-line structures and relationships which must be preserved.
Current merge user interfaces typically have multiple windows for displaying the various file versions to be merged. One window, for example, may be dedicated to displaying the base file, also referred to as the ancestor. Other windows are used to display contributor versions of the file, which are modified versions of the base file. Each contributor version usually is accompanied by a base window showing the original base file and a merge window for displaying the resulting merge between the base version of the file and a contributor version of the file. Some merge user interfaces make the base and the merged file windows optional or leave the two windows out entirely. Each solution is a compromise in usability designed to reduce merge user interface clutter and to reduce the time needed to render file content to the display screen.
The time required for rendering a file to the screen and the ensuing screen clutter are especially problematic when dealing with structured data that is viewed either hierarchically or diagrammatically. Such is the case as trees and diagrams can require a significant amount of time to render visually and further require a large amount of screen area to be displayed. Considering that many merge operations have more than 2 contributors, with each contributor having a tree or diagram view, one can see that the time needed for graphically rendering the material to the screen requires an unacceptable amount of time, particularly for an expert user that is already familiar with the data being rendered.
FIG. 1 is a view of a conventional source code control system graphical user interface (GUI) 100. As shown, GUI 100 includes multiple windows, which add to the overall clutter and complexity of the GUI 100. In particular, the user interface 100 includes a comparison window 105, a first contributor window 110, a base window 115, a second contributor window 120, and a merge window 125. The base window 115 is used to display the original file prior to any changes. As shown, the base window 115 typically includes a split view. The split view accommodates the need to for displaying conflicting deltas, which may not be on the same ancestor element. Though the split window is shown as being vertical, it should be appreciated that such a split window view also can be implemented as a horizontal split window view.
The first contributor window 110 displays a modified version of the base file after editing by the first contributor. The second contributor window 120 displays a modified version of the base file after editing by the second contributor. The comparison window 105 displays information relating to conflicts and differences between the base file depicted in the base window 115 and the first contributor window 110 and the second contributor window 120. Often, the comparison window has three tabs corresponding to views which separate left and right differences and conflicts. The tabbed viewing ability is needed due to the split between left and right viewers. The merge window 125 presents the resulting merge file after incorporating changes from both the first and second contributor versions of the file.
It should be appreciated that each window of GUI 100 usually displays an entire version of the subject file. For example, the first contributor window 110 typically displays the entire version of the file from the first contributor. Scroll controls are provided allowing the developer to navigate throughout the file. Likewise, second contributor window 120 displays the entire version of the file from the second contributor. The merge window 125 presents the entire merge file. As noted, since the size of each version of the subject file can be very large, the time needed to render each file version to the display can be lengthy. The screen real estate needed also is large.
It would be beneficial to provide an interface which can be used for merging files which overcomes the limitations described above.